In real-time media streaming services, such as video streaming, it is important that the media stream arrives to the receivers that is to consume the media in time and without errors. However, for wireless networks, the higher transmission error rate to a wireless receiver, i.e. a wireless UE, generates much higher packet loss compared to a wired receiver. This data loss in transmission causes more degradation to a video stream than an audio stream due to the temporal dependency in video data.
Due to the real-time nature of many multimedia applications, using retransmission to recover from an error usually does not meet the time requirement. As a result, Forward Error Correction, FEC, is naturally used to protect real-time multimedia data. The idea of FEC is to transmit additional redundant information along with the data that need to be protected. In case some packets got lost, these redundant FEC packets can be used by the receiver to recover the lost or corrupted data.
In the following it is briefly described how Internet Protocol/User Datagram Protocol, IP/UDP packet losses occur in Long Term Evolution, LTE, networks. First, IP packets are segmented to smaller Radio Link Control, RLC, packets in the RLC layer, and then the RLC packets are in turn segmented to transport blocks in the Media Access Control, MAC layer. In the MAC layer, a stop-and-wait Hybrid Automatic Repeat Request, HARQ, mechanism is applied to perform retransmissions of the erroneous transport blocks and to correct the majority of transmission errors happened at the air interface. In general, the targeted block error rate, BLER, for initial transmission is set around 10%, which suggest 10% of initial HARQ transmissions over the air interface will be erroneous. In HARQ, there are parameters for controlling the maximum number of retransmission attempts. When the number of retransmission attempts reaches the maximum number, the transport block is considered to be lost in the MAC layer. The default value for retransmission is 3, which signifies that the each transport block has a 0.1% loss probability if we assume uncorrelated transport block loss and the same BLER for the initial transmission and the retransmissions. However, these losses could be highly correlated.
In the RLC layer, a highly reliable sliding window-based ARQ mechanism can be applied to further reduce the packet loss. There are three different RLC modes: Transparent Mode, TM, Unacknowledged Mode, UM and Acknowledged Mode, AM. TM signifies that the RLC layer is completely transparent. UM and AM both contain segmentation/reassembly functions and in-sequence delivery functions. The difference is that there are retransmissions in the AM mode whereas no retransmissions in the UM mode. The RLC packet loss rate not only depends on packet loss rate in the MAC layer, but also on its mode and settings such as RLC window size, reordering timer, and maximum allowed retransmissions. Usually, worse radio channel condition means more retransmission attempts, further resulting in longer delay, higher packet loss probability and lower throughput.
For real-time communication, RLC is usually configured to Unacknowledged Mode, which suggests no retransmissions. Therefore, RLC and MAC layer packet loss should be in similar ranges. With RLC retransmission RLC packet loss should be much lower than RLC and MAC layer packet loss. Finally, there are segmentations to take account when considering IP packet loss. When an IP packet loss is segmented to for example 10 transport blocks in MAC layer, a single transport block loss will lead to whole packet loss. This will increase the IP packet loss rate compared to RLC and MAC loss rate, especially when RLC does not use retransmissions. The exact number of segments to be divided into depends on a lot of parameters, including IP packet size, cell capacity, number of users in cell, radio quality, and the scheduler, etc. This makes IP packet loss rate hard to compute.
Since the redundant packets take extra amount of network resources, a static FEC will cause a lot of overhead when the error rate is low. To address this, adaptive FEC has been proposed. An adaptive FEC will increase or decrease the amount of redundant packets when the packet loss rate is getting higher or lower, respectively. In this way, adaptive FEC can get better balance between bandwidth and Quality of Experience, QoE. Using adaptive FEC for video applications in wireless networks has been an active research area. All adaptive FECs require information to estimate current/future available network bandwidth and packet loss; and decide redundancy rate based on the information. One approach is to estimate the network condition on the receiver side and send feedback to the sender by using a RTCP message, such as described in WO 2013098810.
The network conditions for a UE in a mobile communication network, e.g. LTE network, change all the time, as a result of several reasons. First of all, the UE may move around and may have better or worse link quality depending on the distance to the serving cell. Secondly, even if the UE is stationary, the radio quality could change over time as objects in the environment move. Third, the number of active UEs in a cell may change and result in changed link condition. Finally, the UE may be handed over to another cell, with different number of active users, and different radio qualities, and different cell configurations, thus resulting in changed network conditions.
In some existing solutions, as in e.g. WO2013098810, the receiver of the video flow monitors network conditions such as the loss rate and continually reports this back to the sender. Thus, the sender can adapt the redundancy rate based on the feedback from the receiver. This approach works well when the network conditions do not change much over time. However, in a mobile wireless network, a receiving UE's link quality can change more rapidly and frequently comparing to wired network, which makes the receiver reports based on the past network condition do not work well in real time. The main reason is that the response time for this kind of FEC is a bit slow, as the adaptation of video bitrate and FEC at the sender needs to wait for the response from the receiver after some transmissions. Especially in the case when video is getting started, the sender has no idea about what rate and FEC that should be used. In addition, this kind of end user based packet loss prediction is not as accurate as network based, as it knows much little about the situation in the network.